Developing software applications and products often requires the coordinated efforts of many developers (e.g., software programmers). This coordinated effort is referred to herein as a “software development effort” or “development effort,” and the body of work (e.g., one or more software applications and/or products) being developed by the effort is referred to as a “software development project,” “development project” or “project.” At any given time, as part of a software development effort, multiple developers may be working on different components of a software development project and/or different versions of these components (e.g., for different users or situations). Managing the concurrent development of these different software components and versions is commonly referred to as configuration management (CM). CM software applications (i.e., programs) assist developers and project managers in the management of a software development project, including maintaining coherency between different components and versions.
A software development effort typically involves adding or improving functionality (i.e., adding features) to a product, and fixing functionality that is not working properly (i.e., fixing defects or “bugs”). Typically, one or more fixes, features or combinations thereof (i.e., development items) are grouped together as a development unit called an “issue.” At a minimum, an issue defines one or more development items, and often includes other information. Issues are often tracked as part of a development effort, and tracking information may be added to an issue description, including information indicating that the issue has been resolved. Because of the often significant numbers of issues involved in a development effort, development efforts typically employ an issue tracking system to track the progress of the resolution of each issue.
A primitive issue tracking system may involve the creation of a list of issues on paper, where a description of each issue is written down. Notes may be taken throughout the progress of resolving the issue, and the issue may be checked off when it has been resolved. More often, tracking systems are implemented using a computer system, for example, as part of a CM application. Such computerized tracking systems may provide a unique identifier (e.g., a serial number) for each issue, and provide data fields that enable a user (e.g., a developer, supervisor or project team leader) to track the progress of the issue's resolution.
During the resolution of an issue, the one or more software components (e.g., objects, records, programs, files, directories, etc.) that need to be modified or added to resolve the issue is/are determined. Some issue tracking systems enable an association to be created and maintained between an issue and the one or more software components needed to resolve the issue. More specifically, an association can be created and maintained between an issue and the versions of the one or more software components needed to resolve the issue. As used herein, an “issue resolution” or “resolution” is an abstraction (e.g., a software abstraction such as an object, record, variable or table) defining an association between a an issue and one or more software components and versions thereof that provide a solution to the issue. For example, an issue is created describing a bug, and it is determined that a first version of a file is causing the bug. A second version of the file that resolves the problem is developed, and an issue resolution created that associates the second version of the file with the resolution of the issue.
As described above, a software development effort often involves multiple developers working concurrently on different versions of different software components. Some CM applications provide each developer a “workspace” (defined below) in which the developer can add, modify and delete components of the development project pertinent to the developer's objective. Further, a CM application may maintain one or more versions of the project itself (e.g., branches or streams—defined below), and a developer's workspace may be configured to enable the developer to make changes to a particular version of the project. As used herein, a “version” of a software development project (or other software entity) is a set of software components of the project, and for each software component, a version thereof. It should be appreciated that different versions of a software project (or other type of software entity) may have the same content (e.g., may include a same set of software component versions) or different content. A developer's workspace may be considered a version of the project. It is often desirable to propagate modifications made in a developer's workspace (e.g., an addition, change or deletion of one or more software objects) to other versions of the project, including other workspaces. CM applications often are configured to provide such propagation.
In addition to providing the propagation of modified software components, some CM applications provide an issue tracking system that enables a user to record that an issue resolution has been propagated to one or more versions of the project. For example, the user can make an entry in the tracking system that indicates that a particular issue resolution has been propagated to a particular version of the project. To determine that an issue resolution has been propagated to a version of the project, the user determines the software components and versions associated with the issue resolution, for example, by looking up the issue resolution in the issue tracking system. Then the user determines whether all of the versions of the software components have been propagated to the version of the project, for example, by looking up the list of software components and their associated versions currently in the project.
Thus, known issue tracking systems require a user to manual determine whether an issue resolution has been propagated to particular version of a project, for example, by looking up information on the system. Further, the user must manually record the propagation of the issue resolution. Such manual determination is time-consuming and susceptible to human error.
Some known issue tracking systems allow the definition of an issue resolution to be altered after the versions of the software components defined by the issue resolution have been propagated to one or more versions of a project. Consider the following example. An issue resolution specifies a second version of a file, which resides in a first branch of a project. The second version of the file is then propagated to a second branch of the project, and a user creates a record indicating that the issue resolution is included in (i.e., has been propagated to) the second branch. Then, after the issue resolution has been propagated, the developer realizes that there is another change that needs to be made to the file. The developer then creates a third version of the file in the first branch and alters the definition of the issue resolution to include the third version of the file, replacing the second version. Another example is if the developer adds another file to the issue resolution.
If the record is not updated to reflect that the issue resolution (in its current form) has not been propagated to the branch, then the propagation record is now inaccurate, as the second branch does not actually include the issue resolution. Rather, the second branch includes the earlier second version of the file. Known systems do not have the ability to automatically detect this scenario and update the record, such that user must manually do so.
Thus, known issue tracking systems are susceptible to human error resulting in the maintenance of an inaccurate record of issue propagation. As a result, a customer may be provided a version of a software product that allegedly includes a resolution to an issue (e.g., a bug fix or a new feature), but, in fact, does not include the resolution.
Another shortcoming of known issue tracking systems is that no electronic record is maintained of the history of changes made to an issue resolution (i.e., changes to the set of software component versions included therein). Thus, known systems are limited to maintaining only the current state of an issue resolution, such that the state of an issue resolution (e.g., the software components included therein) at a time in the past cannot be determined automatically.